Migrating to a CORBA environment provides for the opportunity for software architecture reengineering. Use the migration to CORBA as a means for improving your software architecture. An overview of software architecture development is given here.
Well designed software architectures ( we view an architecture here as a collection of frameworks) are key in providing information systems with a long life. The software architecture is the 'glue' that remains in the system regardless of changes to external components. A good architecture will minimize cost as well as provide a stable environment. A stable system does not rely on specific component implementations. Cost will be minimized cost by reducing the complexity of component integration. This reduces programmer training time, development and maintenance costs. Develop the architecture interactively, learning from prototypes.
Make decisions based on market and standards awareness. Align your strategies with market and developed standards. Be wary of leading edge technologies. Having more than a few leading edge technologies can greatly increase your risk of failure. Choose a backup technology for each leading edge technology and develop your architecture so it can adapt to the backup technology. Expect product bugs and delays with leading edge technology and plan accordingly.
Depend on standards to reduce your risk. CORBA users (application developers) should write to the standard and not to specific non-standard product features. The goal is to insulate your application code so it is not effected as the product evolves.
Use the OMG/IDL for specifying the software architecture. The IDL allows for the specification of API's in a language and platform independent manner. The utilization of the IDL can be used independent of CORBA. In addition to ORB's IDL interfaces can be layered on top of Remote Procedure Call (RPC), DCE and library functions.
A well designed software architecture provides: Interoperability between components and systems Extensibility Component interchangeability Cost savings through integration, operation and management savings.
We can think of software architecture as defining the boundaries between the major components of a software system These boundaries are interface specifications which can be expressed in the OMG/IDL. We strive to enhance system adaptability. A large portion of the cost of a software system, about 70 percent [Horowitz 93], are for operations and maintenance. The savings for a well structured vs. a poorly structured architecture typically exceed 50% [ Horowitz 93]. CORBA is an enabler of software architecture and has simplified the creation of good software, providing architectural notations (OMG IDL) and system flexibility built into the ORB's. CORBA does not however design or define the software architecture.
Software architectures are designed by individual chief architects or by design teams. Individual architects can develop conceptually simple and elegant architectures. Once developed it is imperative that the architecture be completely understood by the individuals. Design teams usually create larger more complex architectures, the complexity a result of the inability to compromise and merge viewpoints. Once an architecture is designed, use prototypes and a regular release schedule for updates.
The OMG IDL and the ORB provide two basic sources for the enabling of software architectures. The IDL is a notation for specifying API's. These API's denote system level software boundaries, which is a goal of good software architecture. The OMG IDL provides a compilable linkage between software architecture and implementation. This allows the compiler to verify architectural constraints in the application software. The ORB supports flexibility and transparency in the implementation.
In practice, formal design methodologies have had mixed results. The quality of the people on the team are more critical to success than the methodology. It should also be mentioned that some very competent people will have no concept of what makes a good architecture. Training is recommended for design staff. We will discuss the necessary insights to create an effective architecture.
The first step in the design process include farming and mining activities.
Farming involves the creation of abstractions of the system requirements. The system requirements are represented at the software architecture level. These requirements provide insight into the general operation of the system. It should be noted that the requirements are a snapshot of the users current requirements and while a good software architecture should support these requirements, the architecture must be flexible to handle anticipated and unanticipated future needs. Dependencies on commercial API's or business rules should be isolated to avoid obsolesces.
Mining involves the study of current technology and legacy systems. Models are developed of the existing subsystems. We wish to represent an idealized API for each component. With an understanding of the components, we generalize the components. It is important to study enough components to create a generalized class. To few, and the generalized class could be biased towards one implementation.
Once the background research has been completed, we begin the process of creating the software architecture. This is the 'artistic' step of the process. A designer may start with a strawman to be further refined, or some other method based on experience. Design reviews can play an important role in the design process. This also helps to educate other members as in the structure of the software architecture.
Once the architecture has been stabilized a prototype should be developed. Once the prototype is complete, the changes should be considered very carefully. The updates should be released as discrete updates.
Object wrapping is a practice for implementing a software architecture given pre-existing components. A wrapper provides a more controllable form of a legacy system that is more suitable for integration with other components. Wrappers provide technology migration paths for legacy systems, allowing a component upgrade without affecting the rest of the system.
The wrapper provides a clean interface to the legacy system. Before object wrapping a legacy system has: unique API Unique access mechanism Nonexchangeable data format Limited metadata Inadequate interoperability Limited/proprietary security After wrapping a system should have The desired API Uniform Access mechanism Exchangeable data format Complete/uniform metadata Meets interoperability needs uniform security interfaces.
Object wrapping approaches can be divided into the following categories: Layering - Layering is a mapping from one form of API to another. An example of this would be the layering of a CORBA-based interface over some RPC services. Layering can be used to aggregate existing components or partition complex systems. Data Migration - Many legacy systems are actually very large database applications. Anomalies can exist in these systems that can be handled by migrating the data to a new data model or by developing a wrapper to provide access to the database application. Reengineering Applications - Once an application is wrapped, it can be reengineered to provide increased performance or enhanced maintainability. Middleware - Middleware is a general term used to describe a large array of system integration software. Two major categories of middleware are distributed processing middleware (lower middleware) and database middleware (upper middleware). Commercial products that support CORBA are available in both categories. Encapsulation - An encapsulation is a black-box abstraction that hides the underlying implementation by means of an interface. It completely separates the interface from implementation. CORBA encapsulations hide differences in programming languages, location, operating system and data structure. Wrappers for architecture Implementation - The wrapper provides interoperability between the architecture and legacy systems. These wrappers could provide added value, such as metadata for the legacy system. Metadata is used by applications to discover information about object implementations. Wrappers for mediators and brokers - To support a diverse array of processing services, brokers and mediators are required. Brokers and mediators support such functions as access to disparate information sources, conversion of incompatible data formats and sophisticated search and data presentation algorithms.
Choosing an ORB requires a thorough understanding of an applications present and future software requirements as well as how candidate ORB solutions satisfy these needs. This analysis is usually performed at the software architecture level. After development of this understanding, an informed decision can be made. The following guidelines are based on SAAM (Software Architecture Analysis Method).
This method involves the following five steps: